In today's emergency calling environment (hereafter referred to as “9-1-1” although the invention is applicable to other dialing strings throughout the world), calls are routed to Public Safety Answering Points (“PSAPs”) based almost solely on the estimated location of the caller. If a particular PSAP desires to have their calls delivered elsewhere, they generally have to perform network level changes to affect a re-direction. NG9-1-1 desires to have this capability automated by using policies enacted by the proper authority for the PSAP (hereafter referred to as “PRF Administrator”).
NENA describes a policy routing as “the determination of the next hop a call or event is forwarded to by an Emergency Service Routing Proxy as set forth in NENA 08-003, “Detailed Functional and Interface Specification for the NENA i3 Solution,” Section 5.2.1.5. A PRF is a functional element that can dynamically route calls based on a variety of conditions. These might include time of day (e.g., a PSAP does not take calls between 2:00 a.m. and 6:00 a.m. so their calls are re-routed to a previously agreed upon location), network condition (e.g., if a PSAPs call volume is over a threshold, re-route the calls to a previously agreed upon location), and/or PSAP condition (e.g., if a PSAP is unavailable due to scheduled maintenance, a catastrophic condition, etc., re-route the calls to a previously agreed upon location).
The current industry design (as documented in NENA's i3 specification) does not provide a mechanism for the dynamic (re)routing of 9-1-1 calls based on a user provided geographic parameters. One familiar with 9-1-1 can see that such a capability is needed for temporary, geographically specific conditions such as a chemical spill, a natural disaster, or a scheduled extraordinary event (e.g., The Super Bowl, Olympics, etc.). This invention provides for this geographic-based policy routing of requests for emergency service. The current industry design also does not provide for a mechanism to detect and remedy a set of policies that create a “loop” in call delivery. A simple example of such a loop might be where PSAP A has a current policy in place that re-routes the call to PSAP B. Simultaneously, PSAP B has a current rule in place that routes the call to PSAP A. Such a situation could result in an emergency communication not getting delivered properly or potentially not delivered at all. This invention specifies a method to avoid and remedy looping conditions created by policy routing.